CQ 

(O 
00 

CM 

in 
o 

Q. 

Hi 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(11) EP 0 752 786 B1 

EUROPEAN PATENT SPECIFICATION 



(45) Date of publication and mention 
of the grant of the patent: 
16.02.2000 Bulletin 2000/07 

(21) Application number: 96110363.7 

(22) Date of filing: 27.06.1996 



(51) lntC| 7: H04N 7/167 



(54) Apparatus and method for authenticating transmitted applications in an Interactive information 
system 

Verfahren und Vorrlchtung zur Empfangsbestatigung von ubertragenen Anwendungen in einem 
interaktiven Datensystem 

Apparel! et methods pour rauthentification des applications transmises dans un systeme d'Information 
interactif 



(84) Designated Contracting States: 
DE ES FR GB IT 

(30) Priority: 07.07.1995 US 499280 

(43) Date of publication of application: 
08.01.1997 Bulletin 1997/02 

(73) Proprietor: OpenTV, Inc. 

Mountain View, CA 94043 (US) 



(72) Inventors: 

• Rohatgl, Pankaj 
Sunnyvale, CA 94086 (US) 

• Dureau, Vincent 
Venice, CA 90291 (US) 

(74) Representative: Benech, Frederic et al 
69, Avenue Victor Hugo 
75783 Paris Cedex16{FR) 



(56) References cited: 
WO-A-95/15655 



US-A- 5 420 866 



Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give 
notice to the European Patent Office of opposition to the European patent granted Notice of opposition shall be filed in 
a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 
99(1) European Patent Convention). 



Printed by Jouve. 75001 PARIS (FR) 



EP 0 752 786 B1 

Description 

[0001] This invention relates to a method and apparatus for insuring that data accepted by an interactive television 
system is authorized data. 

s [0002] Interactive television (TV) systems are known from for example United States Patent No. 5,233.654. Interac- 
tive television systems typically involve the transmission of programming and/or control data (hereafter PC-data), as 
well as audio and video information, to respective receiving apparatus. The receiving apparatus decodes the PC-data, 
and applies it to some type of control apparatus for automatic use by the receiver or selective use by the user of the 
receiver. The control apparatus may take the form of a computer, for example, and the use may include downloading 

10 selective e.g., financial data for subsequent user manipulation. 

[0003] As envisioned herein, information in the interactive television system (I TVS) is transmitted in compressed 
digital form. The receiving end of the system includes an integrated receiver decoder (IRD) for receiving and decom- 
pressing the transmitted information and providing decoded audio, video and PC-data to respective processors. The 
audio and video processors may be audio and video reproduction devices or a television receiver and the PC-data 

'5 processor may be a computer. Ideally the system will only provide well tested PC-data provided by authorized service 
providers, and under such conditions there is little likelihood of transmitted information actually damaging respective 
receivers. However, if a large number of service providers are authorized to use the system, it becomes vulnerable to 
a) invasion by unauthorized users and intentional infliction of damage to system users, and b) careless preparation of 
PC-data and consequent unintentional damage to system users. The ability to broadcast PC<lata to tens of thousands 

20 of IRD's simultaneously, multiplies the potential disruption that may be inflicted by ill behaved software many fold. Thus 
there Is a need for measures to assure protection of respective ITVS receivers from both ill behaved and unauthorized 
PC-data. 

[0004] A receiver embodiment of the invention includes an IRD which is responsive to a transmitted program guide 
for selecting signal packets of PC-data. The IRD temporarily stores the selected PC-data. Authorized PC-data will 
25 include a certificate. A PC-data processor is configured to separate the certificate and to check it for authenticity. The 
processor hashes portions of the PC-data and compares the generated hash values with hash values transmitted with 
the PC-data and corresponding to the same portions of PC-data. If the hash values are identical and the certificate is 
authentic, the system is conditioned to execute the transmitted program. 

[0005] A transmitter embodiment includes software generating apparatus for providing an interactive program. The 
30 program is divided into modules and a Directory Module is generated. Respective modules are hashed and the gen- 
erated module hash values are included in the Directory Module, The modules are then conditioned for transmission. 
[0006] The invention will be described with the aid of the following drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 

[0007] 

FIGURE 1 is a block diagram of an interactive TV signal encoding system embodying an aspect of the present 
invention; 

40 FIGURE 2 is a pictorial diagram of a portion of an exemplary AVI signal 

FIGURE 3 is a pictorial diagram of an exemplary transport packet 

FIGURE 4 is a pictorial diagram of the format of an exemplary AVI application, useful in describing the invention. 
FIGURE 5 is a table of the contents of an exemplary transmission unit header. 

FIGURE 6 is a table of the contents of an exemplary Directory Module of a AVI application embodying the invention. 
45 FIGURE 7 is a flow diagram illustrative of the process of applying security/protection to an AVI application embod- 

ying the invention. 

FIGURE 8 is a block diagram of exemplary receiver apparatus embodying the invention. 

FIGURE 9 is an expanded block diagram of an exemplary processor which may be implemented for the processor 

of the FIGURE 8 apparatus. 

50 FIGURE 10 is a flow chart showing operation of a portion of the receiver apparatus of FIGURE 8, and which 

describes a receiver embodiment of the invention. 

FIGURE 11 Is a flow chart of an exemplary process for authenticating a certificate and is an embodiment of the 
invention 

FIGURE 12 is a pictorial representation of a preferred Directory Module format according to the invention. 

55 

[0008] The invention will be described in the environment of a compressed digital transmission system, as for ex- 
ample a direct broadcast satellite system. It is presumed that a single satellite transponder will accommodate a plurality 
of respective TV programs in time division multiplexed format . 
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[0009] Referring to FIGURE 1, a packet multiplexer 16 provides, at its output port, an audio-video-interactive (AVI) 
program. Similar such devices 26 generate alternative AVI programs. A program guide, which includes information 
associating the audio, video and interactive components of respective AVI programs via service channel identifiers 
(SCID's), is provided in a transmission format similar to the AVI programs by a processing element 27. The program 

5 guide and respective AVI programs are applied in transport packet form to respective input ports of a channel multiplexer 
28. The channel multiplexer 28 may be of known construction for equally time division multiplexing respective packet 
signals into a single signal stream or it may be a statistically controlled multiplexer. The output of the multiplexer 28 is 
coupled to a forward error coding (FEC) and signal interleaving apparatus 31 , which may Include Reed-Solomon and 
Trellis encoders. The output of the FEC 31 is coupled to a modem wherein the multiplexed signal is conditioned for 

10 application to. for example a satellite transponder. An exemplary statistically multiplexed packet signal is illustrated in 
FIGURE 2, and an exemplary format for respective packets is illustrated in FIGURE 3. 

[0010] AVI formation is controlled by a system program controller 5. Program controller 5 may have a user interface 
by which particular programs and respective program signal components are selected. The program controller assigns 
respective SCID's for respective audio, video and interactive components of respective programs. The presumption is 

15 made that respective receivers will access a program guide to determine which SCID's associate AVI program com- 
ponents, and then select transport packets from the transmitted signal stream containing the associated SCID's. The 
audio, video and interactive components are assigned different SCID's so that one or more of the components of one 
AVI program may conveniently be utilized in the formation of alternate AVI programs. Using differing SCID's also fa^ 
cilitates editing audio from one program with video from another etc. 

20 [0011] A given AVI program may include a variety of signal component sources. Shown in FIGURE 1 are an interactive 
component source 10, a video source 17, and first and second audio sources 20 and 23 (bilingual audio). The controller 
5 communicates with respective sources for time management and/or enabling functions. The source of video signal 
17 is coupled to a video signal compression apparatus 18, which may compress signal according to the video com- 
pression standard promoted by the Moving Pictures Experts Group (MPEG). Similarly the respective audio signals 

25 from the sources 20 and 23 are applied to respective compression apparatus 2 1 and 24. These compression apparatus 
may compress the respective audio signals according to the audio compression standard promoted by the Moving 
Pictures Experts Group (MPEG). Associated audio and video signals compressed according to the MPEG protocol 
are synchronized with the use of presentation time stamps (PTS), which are provided by a timing element 15. For 
insight into how the audio and video may be temporally related, the reader's attention is directed to INTERNATIONAL 

30 ORGANIZATION FOR STANDARDIZATION, ISO/lEC JTC1/SC29/WG11 ; N0531, CODING OF MOVING PICTURES 
AND ASSOCIATED AUDIO, MPEG93. SEPTEMBER, 1993. 

[0012] The compressed audio and video signals are applied to transport packet formers or processors 1 9, 22 and 
25. Audio and video transport packet processors are known and will not be described. Suffice it to say that the packet 
processors divide the compressed data into pay loads of predetermined numbers of bytes and attach identifying headers 

35 including SCID's, as indicated in FIGURE 3. For detailed information on a video signal transport packet processor, the 
reader is directed to United States Patent No. 5,1 68,356. The packet processors are coupled to the packet multiplexer 
which time division multiplexes the signal components. The transport packet processor may include a buffer memory 
for temporarily storing packetized data to accommodate the multiplexer servicing other components. The packet proc- 
essors include PACKET READY signal lines coupled to the multiplexer to indicate when a packet is available. 

40 [0013] Interactive programs are created, via known techniques, by a programmer operating the interactive compo- 
nent source or programming element 10, which may be a computer or personal computer (PC). In forming the appli- 
cation the programming element 10 interfaces with a memory 11 and memory controller 12, and the completed appli- 
cation is stored in the memory 11 . After completion, the application may be condensed or translated to some native 
code to conserve signal bandwidth. 

45 [0014] In the formation of the application, portions of the programs are formatted into modules, transmission units 
and packets as shown in FIGURE 4. The packets are similar in form to the transport packets described above. A 
transmission unit i consists of a plurality of transport packets. Each transmission unit includes a header packet which 
includes information descriptive of the transmission unit contents, and a plurality of basic packets each of which Includes 
a portion of the codewords of the application. A module is divided into transmission units to facilitate interleaving of 

50 information from different modules. Preferably, interleaving of transmission units is permitted, but interleaving of trans- 
port packets from different transmission units is not. For a more detailed description of the formation of an application 
and transmission units etc. the reader is referred to United States Patent No. 5,448,568. 

[0015] Modules are similar to computer files, and are of different types. A first type of module is a Directory Module 
which contains information to interrelate respective transmission units and modules as an application. A second module 
55 type is a Code Module which comprises executable code necessary to program a computing device at a receiver to 
perform or execute the application. A third module type is a Data Module. Data Modules include non-executable "data" 
used in the execution of the application. Data Modules tend to be more dynamic than Code Modules, that is Data 
Modules may change during a program while Code Modules generally do not. A fourth type of module is designated 
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a Signal Module. This module is a special packet including information to trigger receiver interrupts, which may be 
utilized for synchronization of e.g., video with application program features, or to suspend operation of an application, 
or to re-enable operation of a program etc. Synchronization is effected via inclusion of presentation time stamps. Data, 
Directory, Code and Signal Modules are examples of the PC-data. 

5 [0016] The respective modules may be error coded by the programming element 10. For example the entire module 
may undergo cyclic redundancy coding CRC, and error check bits may be added to the end of the module. 
[0017] Each transmission unit, TU, is configured with a header including information about the TU. Table I, shown 
in FIGURE 5. illustrates exemplary types of information included in each TU header packet . The header includes a 
version number. The version number is included to indicate when a change is made to the application during the 

10 presentation of the AVI program. A receiver decoder may be arranged to update an executing application responsive 
to detecting a change in version number. The Module ID is similar to a computer file identifier and is provided by the 
application programmer. The Module Transmission Unit Byte Offset is a number which indicates the byte location in 
the module of the first code/data byte of the payload of the TU. The Length (bytes) Of Transmission Unit indicates the 
size of the TU and/or the location of the last code/data byte in the TU. 

15 [0018] Table II of FIGURE 6 illustrates representative types of data included in the Directory Module. The Directory 
Module includes a header with an Application identifier, AID, afield indicating the application type, a field which includes 
type qualifiers, a field which indicates the amount of memory required to store and execute the application, a field 
indicating the number of modules contained in the application, and a field or fields (FIRST SECURITY INFORMATION) 
which may include security data such as authenticating data. It will be appreciated that the respective fields listed 

20 above, or those that follow, need not occur in the order illustrated. A data portion of the Directory Module includes data 
for each module similar to the header data for the respective modules. In addition there is a string table which is a list 
of respective application module names in ASCII format. The data section for each module may also include a field or 
fields (FURTHER SECURITY INFORMATION) for security data related to the respective module. Alternatively, this 
data may be included with the more general directory information in the first security information field. The contents of 

25 the module security information fields will be discussed in detail below. 

[0019] For transport packet formation, the interactive component source 10 may be programmed to generate the 
actual transmission units and transport packets, however in the embodiment of FIGURE 1 , a separate code/data packet 
processor 14 is included. The code/data packet processor accesses the respective areas of the memory 11 through 
the memory controller 12 and generates packets in a sequence representing a respective application (FIGURE 4). 

30 [0020] The packet multiplexer 16 is arranged to provide packets according to a particular schedule. The schedule 
is nominally determined by the bandwidth requirements of the AVI components. If there is multiplexing contention 
between the respective AVI components it is preferred that the signal component with packets that occur least frequently 
be assigned the higher multiplexing priority. 

[0021] The specifics of the packet multiplexer 1 6 will not be described because multiplexing is a mature art and those 

35 skilled in digital signal processing will readily be able to design a multiplexer to satisfy their particular requirements.. 
Suffice it to say that the packet multiplexer 1 6 may be arranged using three state logic switches with input ports coupled 
to the respective component signals and their output ports coupled to the multiplexer output port. A state machine may 
be arranged to control the logic switches responsive to priorities established by the controller 5 and the respective 
packet ready signals provided by the packet formers. 

40 [0022] Security in the AVI system is based on the close integration between techniques implemented by the AVI 
system controller and security codes resident in all AVI system compliant receivers. The security is based on public 
key cryptography using the Rivest, Shamir, and Adieman, RSA. algorithm or the Data Encryption Standard, DES. The 
algorithm preferred by the present inventors is the RSA algorithm, using modulus and exponent sizes which are re- 
spectively multiples of four (eight-bit) bytes. The general type of security protection resides in authentication of a cer- 

45 tificate supplied with Directory Modules, and hash values generated over respective other application modules. 

[0023] A special class of RSA protocols is that in which the public exponent is 3. An advantage resides in the fact 
that signature checking speed may be enhanced by inclusion of "helping* information of the type described below 
[0024] Consider that a receiver is to verify that S is a RSA signature over data D, where the public modulus and 
exponent are N and 3 respectively. To verify, the receiver essentially has to show that S^ = D(mod N). Nominally this 

50 requires a division/modulo operation by N, which Is computationally difficult and time consuming. Since multiplication 
isacomputationally simpler and faster operation, a checking operation which relies on multiplication rather than division 
will significantly speed up the operation. 
[0025] Consider the quotients Q1 and Q2 defined as follows 

55 

S^/N = 01 + R1 ; S*R1/N = Q2 + R2; R2 = D; 
if S3=D(mod N). That is, the values 01 and 02 are whole number quotients derived from the signature by division by 
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N. R1 and R2 are respective remainders after division. Given any N, S and D of size at most T bits, wliere S < N and 
D < N, then tliere exist quotients Q1, Q2 of size at most T bits which will verify = D(mod N) using the algorithm 
outlined immediately below. If the values Q1 and Q2 are calculated by the application programmer (e.g. in non-real 
time) and transmitted within the Directory Module with the signature S, it can be shown that a fast check on the signature 
5 may be performed as follows. 

[0026] At the receiver, extract S, Q1 , Q2 from the Directory Module and; 



10 



15 



20 



1 . compute 

2. compute 

3. compare 
else if A> B 

4. compute 

5. compare 
else if C < N 

6. compute 

7. compute 

8. Compare 
else If E > F 

9. compute 

10. Compare 



A=S2 

B = Q1 times N 

A > B; If A< B quit, signature cannot check, 
C = A-B 

C < N; If C > N quit, signature cannot check, 

E = C times S 
F = Q2 times N 

E > F, If E < F quit, signature cannot check, 
G = E -F 

G = D, if not, signature does not check. 



Note that all arithmetic operations are simple multiplications or subtractions. The detection of an erroneous signature 
may occur at steps 3, 5, 8 or 1 0. If an erroneous signature is detected at steps 3 or 5, very little computational time 
has been expended. 

25 [0027] The AVI receivers are provided with the public keys (and desirably helping quotients Q1 and Q2) of the re- 
spective system providers tor decrypting signed certificates included with PC-data to determine program authenticity 
If program authenticity is not confirmed, the received application is immediately dumped from the receiver. Central to 
such a security system is the assignment of unique identifiers, ID'S, to application providers and the system controller 
or server. The system controller allocates unique e.g. 32-bit ID'S to each trusted AVI application provider and also 

30 issues a certificate for the application provider's public key. The certificate is essentially the system controller's digital 
signature on the application provider's public key and includes fields such as the expiration date of the certificate, the 
ID of the provider, and a limit on the amount of storage an application with this ID can use In the file system of the 
receivers. The system controller may employ a plurality of different private-public key pairs, and the certificate may 
include flags to designate which of the plurality of public keys the receiver should use to decrypt respective certificates. 

35 [0028] A certificate for application providers will nominally include: 



CERTIFICATE_FLAGS (which identify the certificate type and may include the system controller's public key flag); 
PROVIDERJD, (which indicate length of provider ID); 
PROVIDER_EXPIRE, (which indicates application lifetime); 
40 PROVIDER_AUTHORIZATION_FLAGS, 

PROVIDER_STORAGE_LIMIT, (which indicates allotted receiver memory); 
PROVIDER_NAME, (the application provider's name) 
PROVIDER_FIXED_CERT, (which is the providers public key). 



45 [0029] This foregoing certificate information is hashed modulo 1 28, and the hash value is appended thereto. 

[0030] The CERTl FICATE_FLAGS mentioned above include authorization flags which grant/deny the receiver proc- 
essors access to privileged actions. Examples of representative privileges accessed via flags are listed immediately 
below and include; 

50 1 , the ability to be downloaded from a broadcast link; 

2. the ability to be downloaded from a local link (e.g. connected via a local IRD port); 

3. the ability to be downloaded from a local remote link (e.g. via a telephone link); 

4. The ability for an application to switch tracks in the context of the same program (e.g. to switch between video 
tracks 1 and 2); 

S5 5. the ability to establish a broadcast connection (e.g. to change TV programs or channels); 

6. the ability to establish a local connection; 

7. the ability to establish a remote connection; 

8. the ability to control external devices; 
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9. the ability to download unchecked modules; 

10. the ability for an application to use cryptographic features; 

11 . the ability for an application to request the user for permission to access files which have user restrictions; and 

12. the ability to activate a resident OCODE monitor for remote debugging. 

5 

These flags are part of both the provider certificate and the application authorization field directory. An application must 
have the authorization flags set at both locations before it is permitted to perform the privileged action. Respective 
receivers contain a BOX authorization mask, in nonvolatile storage, which is programmed to permit access to particular 
privileges, or to prevent certain privileged actions. 

10 [0031] Each application provider selects his own cryptographic public-private key pair, and has his public key certified 
by the AVI system controller (for example by notarized request). The application provider is constrained by certain 
guidelines in selecting the public key. The constraints relate to the capabilities of the receiver hardware. In particular, 
near term consumer electronic receivers will include minimal memory and relatively unsophisticated processors, factors 
which affect authentication processing speeds and times, and thus the size and form of public keys. Examples of 

IS constraints may be that public keys are to be 512 bits or less and that the number of bits be a power of two etc. 

[0032] A special group AVI system ID may be reserved for programs designed to perform receiver or system main- 
tenance. This system ID will be attached with a service provider ID. If a program contains both the special group ID 
and an authentic provider ID, the corresponding maintenance program may obtain access to more secure portions of 
the receiver, depending upon the ID of the particular provider. For example the application provider may be the system 

20 controller and the attached application may be for updating entitlements in a smart card, or perfomnlng a system per- 
formance check. Alternatively, the application provider may be associated with impulse buying commercials and the 
program may be related to checking a users debits against his credit, or to facilitate revenue collection, etc. On the 
other hand, if a group I D is not the special group AVI system I D, the functions available to the application may be limited 
to functions available to all applications. 

25 [0033] Manufacturers of particular receiver apparatus may be assigned special manufacturer ID's. Any application 
having the manufacturer ID may be authenticated by a special authentication process, resident in the receiver, and 
implemented by the manufacturer during assembly of the receiver. Programs containing the manufacturer ID will access 
only receivers produced by the particular manufacturer, and may function to access a particular set of functions built 
into the receiver by the manufacturer. This type of application may be utilized to upgrade receiver operating software. 

30 [0034] There may also be network operators who have software/hardware resident in particular receivers. These 
network operators may also be assigned special ID's to allow selective access to the softwareytiardware of all network 
receivers. The network operators may include their own authentication process resident in the softwareyhardware of 
the network receiver. 

[0035] Whether an application is a special system type, or a manufacturer type or a network type is indicated in the 
35 Directory Module (Table II) in the Application Type field. The Application Qualifier field may include Information identi- 
fying the manufacturer, or network operator, etc. 

[0036] Security is applied to an application as follows. After an application provider has generated an application 
and fonmed respective modules including the Directory module, he determines which parts of the application are to be 
protected. In all instances the Directory Module will be protected. In addition each module containing an entry point 

40 will be protected. Modules without entry points are protected at the providers discretion, and Data Modules are protected 
at the providers discretion. It should be recognized that portions of the data in data modules may frequently change, 
and thereby put a relatively heavy security processing burden on the encoder and receiver, if Data Modules are pro- 
tected. Therefor Data Modules may frequently be transmitted unprotected. Having selected the modules to be protect- 
ed, the provider forms a list of the modules selected for security protection, and the mode of protection for respective 

45 modules, and enters this list in the Directory Module in the fields designated security information. In a particular AVI 
system this module list may be included in general directory information i.e., the first security information portion of the 
Directory Module. In an alternative AVI system, information indicating whether a particular module is protected may 
be included only in the further security information fields of the respective module in the directory. Part of the receiver 
system programming will include a routine to examine the Directory for module security information, and perform se- 

50 curity processing on respective modules according to this information. 

[0037] Module protection may take several forms. The first is simply to encrypt the selected module with the appli- 
cation providers private key A second method is to perform a "hash" function over the module and include the "hash" 
value in the Directory Module in the further security information field for the respective module. A third method is to 
perform a hash function over the module, include the hash value in the Directory Module and encrypt the selected 

55 module with the application providers private key A fourth method performs a hash function over the selected module, 
attaches the hash value to the module, encrypts the module plus hash value, and places a replica of the encrypted 
hash value In the Directory Module. In each of the foregoing examples, security processing of the Directory Module is 
done after all other modules are processed and the security information for respective modules has been entered in 
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the Directory Module. 

[0038] The preferred method comprises performing hash functions over respective modules, inserting the respective 
hash values in the further security information fields of the directory module and subsequently performing a hash 
function over the Directory Module. The hash value of the Directory Module is then encrypted with the providers private 
5 key. 

[0039] A trusted application provider will be assigned a signed certificate which includes items such as the providers 
public key, the providers ID, an expiration date of the certificate, possibly the amount of storage allocated the provider 
at the receiver etc. This certificate is signed with the system controller's private key The encrypted hash value is 
appended to the signed certificate and the combination is appended to the Directory Module. The directory Module 
10 and all other modules are provided to the system controller in plaintext. Data Modules which are selected for protection 
and which are frequently changing, are protected by means of a signature of the provider on the hash value over the 
Data Module, which signature is made part of the respective module. 

[0040] It is possible that the application provider is in fact an overseer of a subgroup of lesser application providers. 
In this instance, the application provider may provide a sub-certificate signed with the application providers private key 
IS and including a sub-providers public key the sub-providers ID, an expiration date of the certificate, possibly the amount 
of storage allocated to the sub-provider at the receiver etc. This sub-certificate will also be appended to the Directory 
Module along with the certificate assigned the application provider. 

[0041] The preferred mode of protection is not secure in that it does not preclude prying eyes from detect ing/inter- 
preting the transmitted information. However the protection, i.e., inclusion of the certificate and hashing of the data. Is 
20 advantageously simple to perform and does provide assurance that the data comes from an authorized source and 
that the integrity of the received data is insured, (if authenticated at the receiver). 

[0042] Untrusted application providers, i.e., providers who may be careless in application generation and threaten 
the integrity of an AVI service, are not provided certificates to be appended to their respective applications. Applications 
provided by untrusted providers are subjected to certification by a trusted certifying authority The certifying authority 

25 rnay inspect the integrity of the application and then process the applications of the untrusted application providers for 
protection purposes, and ultimately pass the processed application to the system controller. 
[0043] Security processing will be further described with reference to FIGURES 1 and 7. FIGURE 1 includes distinct 
hashing and encrypting elements 29, and 30, however it will readily be recognized, by ones skilled in the art of digital 
signal processing, that both functions may be performed in software executed by the \iPC or digital signal processor, 

30 DSP, which may be included in the element 1 0. Once the application has been generated and stored {40} in the memory 
11, the programmer will select/determine {41 } the modules which are to be security protected. These modules will be 
tagged with an index (i). The Directory Module is assigned the highest index so that It will be processed last. Each 
module to be processed is assigned a "Change" flag which is set to a "1". The AVI system repeatedly transmits the 
application during an AVI program. Nominally Code and some Data Modules remain unchanged during the program, 

35 but some e.g., Data Modules may change. During the repeated transmissions of the application it is preferred not to 
re-process unchanged modules for security, but rather only to reprocess the modules which actually change. The 
"Change" flags are established to alert the security processing function which modules require re-processing due to 
changes during the duration of a program. Initially the "Change" flag of each module to be security protected is set to 
the change mode. The element 10 also determines if a certificate from the system controller is available. 

40 [0044] An operating index "1" is set to zero {42} and the first module, M(0), is accessed {43} from the memory 11 . 
The "Change" flag for the module is tested {44} and reset {45}. If the module has been previously processed and the 
"Change" flag indicates no change, the system jumps to step {56}, increments the index "i" and accesses the next 
module. If the "Change" flag indicates that a change has occurred in the module, it is applied {46} to a HASH function 
processor 29. The particular hash function is maintained relatively simple to limit processing requirements imposed on 

45 respective receivers. The function is preferably a one-way function. The hash function should be computationally fast 
and extremely difficult to decipher or break. An exemplary hash function is based on a vector W of 256 codewords w^ 
each 128 bits in length. Data to be hash processed (hashed) is segmented Into 256-blt exclusive blocks of data D, 
where D = d^ , dg, dg, d4, dgse- A basic hash function BH(D) is defined: 



BH(D)= X dxWx mod 2128 
x=l 

55 If there are n blocks of data D, n values, , B2, 83, . . . 8^, each 1 28 bits In length, of the function BH(D) will be generated. 
To compute the hash over the whole data , the intermediate results Bj are combined as follows: Let <Bi,Bj> represent 
the 256 number obtained by concatenating the 1 28 blocks Bi and Bj. Then define H(D), the hash over the data as; 
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H(D) = BH(<BH(„.(<BH(<BH(<B^,B2>),B3>),B4>), -),S^>)- 

Alternatively the function H(D) may be of the form; 

H(D) = B^XOR BgXOR B3 XOR....B„. 

A preferred hash function for hashing modules, is the publicly known function MD5 (MD stands for Message Digest 
and MD5 is described by R. Rivest, THE I^D5 MESSAGE DIGEST ALGORITHM, RFC 1321, April 1992). Once the 
module is hashed, the module is tested {47} to determine if it is expected to be changing during the program. If it is 
expected to change, the hash value H(D) is not placed in the directory, by rather is appended {48} to the module stored 
in the memory 11. (Alternatively, the hash value may be signed (encrypted) with the providers private key, and then 
appended to the module stored in memory 11). The index i is incremented {56} and the next module is accessed from 
memory. If at {47} the module is determined not to change, a test {49} is made to determine if the module is the Directory 
Module. If it is not, the hash value H(M(i)) for module M(i) is placed in the Directory Module {50} in either the first 
security information field, or in the further security information field for the respective module. The index i is Incremented 
{56} and the next module is accessed from memory. 

[0045] If at test {49} the module is determined to be the Directory Module, the hashed value H(M(i)) Is applied to the 
encryptor 30 wherein it is encrypted with the application providers private key. (If desired, the entire Directory Module 
may be applied to the encryptor for encryption at this juncture.) The certificate is fetched {52} and the encrypted hash 
value Is appended thereto {53}, and the certificate with the hash value appended is attached {54} to the Directory 
Module in memory 11. A flag is set {55} which indicates to the data packet processor/program controller, that the 
program is ready for transmission. The system jumps to step {42} and the index is reset to zero. The system then 
proceeds to check if modules change and only changed modules are rehashed, during repeat transmissions of the 
application during a program. As noted earlier, an application provider may include other signed information/certificates 
which may be appended to the Directory Module. Signing of such information is performed in the encryptor 30 using 
the providers private key. 

[0046] In an alternative embodiment, the encryption step 51 may be eliminated. In a still further embodiment, all hash 
values for all hashed modules may be encrypted. 

[0047] FIGURE 12 illustrates the format of a preferred Directory Module. The Directory Module is in plain text. Only 
the Directory signature (hash value) and the certificate are encrypted, the former with the provider's key and the latter 
with the system controller's key. In addition, when respective modules are hashed, each such module may be preceded 
with an ASCII version of some predetermined text associated with the system controller/provider such as the text 
''OpenTv(TM)" before hashing, so that respective module signatures are, for example, the hash value H(OpenTv(TM)) 
+Module), and the Directory Module signature is the encrypted value of H(OpenTv(TM))+Directory Module). This is 
indicated in Figure 1 with the box OTV attached to the memory 11, and is meant to imply that a digital version of the 
text ''OpenTv(TM)'* is stored therein and may be multiplexed with the respective modules when they are read out and 
applied to the hash function element 29. 

[0048] The Directory Module in FIGURE 12 illustrates the preferred format for the AVI system designated OpenTv 
™ being developed by Thomson Consumer Electronics Inc. The formats of certificates, public keys and signatures 
used therein are described immediately below. 

[0049] All certificates, keys and signatures will have multiple byte fields in BIG-ENDIAN format. This architecture 
independent format facilitates portability across different receiver architectures. Any OpenTV certificate is a combina- 
tion of a fixed structure followed by a variable length part, which includes the public key being certified and the signature 
of the OpenTV controller. 

[0050] There are two classes of certificates that will be issued by the OpenTV controller. 

1. Producer(provider) Certificates which are given to application producers. 

2. Server (system controller) Certificates which are specific to a transaction server to which applications from a 
producer (provider) can establish secure communications. 

[0051] In addition, a USER certificate may be issued by the controller. This certificate will never be parsed internally 
by OpenTV, but only made available to the external world. The OpenTV system will only know the size of this certificate. 
Apart from an Open TV specific 4 byte header, the remainder of the certificate structure may be maintained confidential, 
and may be a standard X.509 certificate. 

[0052] The following are the sizes for common parts of certificates. 
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CERTIFICATE_FLAGS_LENGTH (4 bytes) 
PUBLC_KEY_SIZE_LENGTH (4 bytes) 

An OpenTV controller issued certificate starts with a 32-bit flag structure which describes the certificate. The location 
5 and meaning of the various flags are described thusty. 

[0053] The flag for possible extensions to the OpenTV certificate structure is set for the Basic Open TV certificate; 
not to be set for extensions. The flags are defined as follows 

BASIC_CERTIFICATE (0x80000000) 

10 

[0054] Exactly one of the following 3 flags will be set. 

SERVER_CERT!F1CATE (0x40000000) 
PRODUCER_CERTIFICATE(0x20000000) 
IS USER.CERTIFICATE (0x10000000) 

[0055] There is divergence between the SERVER/PRODUCER certificates and the USER certificates as to the in- 
terpretation of the 32 bit field. If the certificate has the appearance of a USER certificate then the last 16 bits of the 
field are actually its size including the initial 32 bit field. 

20 [0056] Regarding the SERVER/PRODUCER flags, after examining the first four bits, the entity being certified is 
known, or the certificate is considered to be an extension beyond the current system. The next four bits indicate which 
OpenTV controller public key has been used to generate the signature. They represent a number N from 0-15. If 0 <= 
N <= 1 4, the N'th embedded public key is to be used. If N == 1 5 then the public key to be used is the latest key received 
through an EXTERNAL trusted channel. Internally in the system the key numbers can only increase. That is, if internally 

25 the key is 5 and a certificate with key 6 occurs and is verified, then the internal key becomes 6 and certificates with 
keys less than 6 will not be accepted. Finally, if and when all internal keys break, the public key would be accepted 
only from EXTERNAL trusted channel. 

[0057] The next byte is resen/ed for a description of the certificate. Currently it is unused. The next two bytes provide 
information about the Producer/Server and the Key being certified. The first byte contain flags describing the algorithm 
30 with respect to the public key; this is common to both server and producer The next and last byte are different for 
Producer and Server so they are described separately. 
The algorithm byte flags are: 

RSA_3_WITH_MD5(Ox00008000) 
35 RSA_WITH_MD5 (0x00004000) 

The last byte for the PRODUCER certificate currently has no flags defined. The last byte for SERVER certificate cur- 
rently has one flag defined to indicate whether the server is constrained. From a functional standpoint, the constrained 
sender does not require any information about the connecting party when it first establishes a secure link. This makes 
40 link establishment much faster. 

SERVER_CONSTRAINED (0x00000080) 
[0058] The externally available fixed part of a Producer Signature consists of a two byte flags field which specifies 
the type of signature, and a 2 byte field which gives the size of the signature. 

45 PRODUCER_SIGNATURE_FLAGS_LENGTH(2 bytes) 
PRODUCER_SIGNATURE_SIZE_LENGTH(2 bytes) 

Currently only one flag is meaningful, the assisted flag. If the producer's signature algorithm is RSA_3__WITH_MD5, 
as specified in the certificate for the producer then the producer has the option of adding additional help data after the 

50 signature for faster checking, and this is designated 
PRODUCER_SIGNATURE_ASSIST (0x8000) 
[0059] The Public Key Structure (for RSA) for producers, servers and OpenTV boxes will now be described. For 
portability, the modulus and exponent sizes MUST BE A MULTIPLE of 4 BTYES. AlsoOpenTv requires that if a modulus 
size is stated to be S bytes, then the first 32 bits of the modulus when represented In big endian format must be NON 

55 ZERO. This is not a limitation since the size can then be stated to be S-4 or less. 
The public key consists of: 
fixed _public._key_t, 
followed by 
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exponent (in big-endian byte format) 
followed by 

modulus (in big-endian byte format) 
A producer/server certificate consists of a cleartext part which contains a descriptor of the certificate by the OpenTV 
s controller followed by the public key of the producer/server of data type described above. In addition there is an enci- 
phered part which is the digital signature S of the OpenTV controller on data which depends on the cleartext data. A 
producer/server at this stage has a choice of either using only S or adding additional data (e.g., Q1 and Q2) beyond 
the signature to make it easier to check. 

[0060] The producer/server needs to add 4 bytes of information between the Cleartext and the Signature S, and 
10 possibly some information beyond S to assist in checking. The 4 bytes of information include fields for flags and the 
size of the total amount of data consisting of the signature and help information. 
The sizes of these two fields are: 

CERTIFICATE_SIGNATUREJNF0_FLAGS_LENGTH(2 bytes) 
IS CERTIFICATE_SIGNATURE_SIZE_LENGTH (2 bytes) 

Only one flag is currently defined, the RSA_3_ASSIST flag. If set, there is help information beyond the signature S, 
which are the two quotients Q1 , Q2 described herein above. This flag is defined; 

20 RSA_3_ASSIST (0x8000). 

The foregoing describes the state of encryption at the module level. This may be overlain with a further encryption at 
the transport packet level. That is, when respective modules are divided into transport packet pay loads for transmission, 
the payloads may be encrypted independent of the authentication process. 

25 [0061] Returning to the general description of the system, two way communications between providers and receivers, 
by telephone modem for example, will incorporate encrypted communications using RSAor Data Encryption Standard, 
DES cryptography for example. The session key will be set up using public key cryptography An application must 
present a certified version of the public key of the server with which it wishes to communicate. A session key is estab- 
lished only if the application provider's ID matches the server ID on the certificate, and the key exchange will use the 

30 public key contained in the certificate. 

[0062] FIGURE 8 illustrates in block form, a portion of AVI signal receiver or IRD including elements of an inverse 
transport packet processor. Signal is detected by an antenna 80 and applied to a tuner detector, 81, which extracts a 
particular frequency band of received signals, and provides a baseband multiplexed packet signal. The frequency band 
is selected by the user through an IRD system controller 89 (hereafter IRD controller) by conventional methods. Nom- 

35 inally broadcast AVI signals will have been error encoded using, for example, Reed-Solomon forward error correcting 
(FEC) coding. The baseband signals will thus be applied to a FEC decoder, 82. The FEC decoder 82 synchronizes 
the received video and provides a stream of signal packets of the type illustrated in FIGURE 3. The FEC 82 may provide 
packets at regular intervals, or on demand, by for example, memory controller 87. In either case a packet framing or 
synchronizing signal is provided by the FEC circuit, which indicates the times that respective packet information is 

40 transferred from the FEC 82. 

[0063] Only packets from a single AVI signal may be processed by the receiver at one time. In this example it is 
assumed that the user has no knowledge of which packets to select. This information is contained in a program guide, 
which is a special program consisting of data which interrelates program signal components through their respective 
SCID's. The program guide is a listing for each program, including the SCID's for the audio, video, and data components 

45 of respective programs. The program guide (packets D4 in FIGURE 2) is assigned a fixed SCID. When power is applied 
to the receiver, the IRD controller 89 is programmed to load the SCID associated with the program guide into a SCiD 
detector 84, which may be a bank of matched filters. When the program guide SCID is detected, the memory controller 
87 is conditioned to route the corresponding packet payload to a predetermined location in the memory 88 for use by 
the IRD controller, 

50 [0064] The IRD controller waits for a programming command from the user via an interface 90, which is shown as 
a keyboard, but which may be a conventional remote control, or receiver front panel switches. The user may request 
to view a program provided on channel 4 (in the vernacular of analog TV systems). The IRD controller 89 is programmed 
to scan the program guide list that was loaded in the memory 88 for the respective SCID's of the channel 4 program 
components, and to load these SCID's in the SCID detector 84. 

55 [0065] Received packets of audio, video or data program components, for a desired program, must ultimately be 
routed to the respective audio 93, video 92, or auxiliary data 91, (94) signal processors respectively The data is received 
at a relatively constant rate, but the signal processors nominally require input data in bursts (according to the respective 
types of decompression for example). The exemplary system of FIGURE 8, first routes the respective packets to pre- 
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determined memory locations in the memory 88. Tliereafter the respective processors 91-94 request the component 
packets from the memory 88. Routing the components through the memory provides a measure of desired signal data 
rate buffering or throttling. 

[0066] The audio, video and data packets are loaded into respective predetermined memory locations to enable the 

s signal processors easy access to the component data. Pay loads of respective component packets are loaded in the 
appropriate memory areas as a function of the corresponding SCI D's, and control signals provided by the SCID detector 
This association may be hardwired in the memory controller 87, or the association may be programmable. 
[0067] The respective signal packets are coupled from the FEC 82 to the memory controller 87 via a signal descram- 
bler 86. Only the signal payloads are scrambled and the packet headers are passed by the descrambler unaltered. 

10 Whether or not a packed is to be descrambled is determined by the CF flag (FIGURE 3) in the packet prefix, and how 
it is to be descrambled Is directed by the CS flag. This packet scrambling is independent of the application module 
security processing described above. The descrambling apparatus may be realized with conventional decryption ap- 
paratus, and may be utilized to perform decryption of received certificates and other data as required. However in the 
following description of processing transmitted applications, decryption is performed by other apparatus. 

75 [0066] An AVI system may include a number of devices capable of operating with the PC-data portion of an AVI 
signal. For example in FIGURE 8 both of the AUX1 and AUX2 processors may be responsive to the PC-data portion 
of an AVI signal. The AUX1 processor may be a personal computer, PC. arranged to detect transmitted stock market 
data and to manipulate same with a transmitted interactive application. AUX2 may be a television system arranged to 
permit interactive impulse buying in conjunction with transmitted interactive commercials. Note, interactivity may be 

20 facilitated with the aid of a telephone modem (not shown) interconnected with FIGURE 8 system. In addition the IRD 
controller 89 may be programmed to process and execute transmitted applications, particularly for system maintenance. 
The receiver functions related to execution of transmitted interactive applications will be described in the context of 
the IRD controller 89 operating with the transmitted application. (It should be noted, that interactivity does not neces- 
sarily mean that the user interacts with the provider, though this is one aspect of interactivity Interactivity also includes 

2S the concept of a user being able to affect the signal/system at the user's end of the system in accordance with a 
transmitted application, particularly in the realm of educational programs.) 

[0069] FIGURE 9 shows the IRD controller of FIGURE 8 in more detail. The IRD controller 89 is shown with a Hash 
function processor 96, a decryptor 97, a modem 98 and an EPROM 99. The hash function generator 96 and the 
decryptor 97 may be realized in either hardware or software. The controller processor {|iPC) may include random 
30 access memory, RAM, and read only memory ROM, for programming general system instructions. Other system in- 
structions are contained in the EPROM 99. The ROM and the EPROM are programmed at manufacture so that the 
system is operable. However in this example, the EPROM may be reprogrammed to update system functions via an 
interactive transmitted program. 

[0070] Assume that at manufacture, the system is programmed to look for a system maintenance SCID between 1 : 
35 00 AM and 4:00 AM on mornings that the receiver is not in use, so that the system provider can update respective 
receivers with new system enhancements. Between 1 :00 AM and 4:00 AM on mornings that the receiver is not in use, 
the |iPC will program the SCID detector to look for packets that contain the system maintenance SCID, and prepare 
the memory 88 to receive program data. An example of program module detection is illustrated in FIGURE 10. 
[0071] The programming for SCID detection and memory preparation is part of the start up processes {100}. Once 
40 the SCID detector is programmed the system idles {102} until a packet containing the system maintenance SCtD is 
detected. When such packet is detected, the packet is tested {104} to determine if it contains a transmission unit or 
module header. If it does not, the packet is discarded and the system waits {102} for the next application packet. It is 
assumed that the information necessary to load any application program is setf contained in the program (TU headers 
or Directory Module header), hence the system is constrained not to load any detected packets until a packet with the 
45 appropriate header information is available. When an appropriate packet is detected, Its payload is loaded {106} in the 
memory 88. The system waits {1 08} for the next system maintenance packet, and when it Is detected it is loaded {110} 
in the memory 88. A test {112} is made after each packet is loaded in memory to determine if a complete module has 
been loaded. If the module is not complete, the system jumps back to step {108} to await the next packet. If the module 
is complete such is noted in a listing {114}. 
50 [0072] A further test is made {116} to determine if the completed module is a Directory Module. If it is, the system 
will immediately attempt to authenticate the application provider. The certificate appended to the Directory Module is 
decrypted {1 22} and its contents are checked { 1 24}. If the contents of the certificate are not authentic, a warning display 
is activated to inform the user that an unauthorized provider was detected. At this point a number of alternatives are 
possible, including a) restarting the process at step {100}; b) shutting down the process for twenty four hours; c) dis- 
ss carding the Directory Module and waiting for the next Directory Module; etc. Figure 11 shows the authentication process 
in more detail. If at test {116} a Directory Module is detected, the certificate and encrypted hash value appended to the 
module are accessed {1 221 }. The certificate is applied to the decryptor 97 and decrypted {1 222} using the AVI system 
controller's public key which has been previously distributed to respective receivers and stored in the receiver. The 
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decrypted certificate is applied to the ^iPC {1241}. The |iPC accesses corresponding items from the EPROM, and 
compares {1 242} relevant corresponding items. For example the certificate will include an ID which is compared against 
a list of authorized ID'S, in addition the certificate may Include an expiration time and date which is compared against 
the current time and date etc. If the compared items check {1 243} against corresponding items stored in the receiver, 

5 the application provider's public key, which was transmitted in the certificate, is applied to the decryptor and used to 
decrypt {1244} the encrypted hash value appended to the Directory Module, or to decrypt any other encrypted data 
provided by the application provider (At this juncture, If the entire Directory Module is encrypted, it may be accessed 
from memory and decrypted while the application provider's public key is applied to the decryptor.) On the other hand, 
if the compared Items prove not to be authentic or the certificate has expired, the warning is displayed {130}. 

10 [0073] If the application provider is proven to be authentic, the Directory Module is applied to the hash function 
element 96 and hashed {1 26}, and the hash value is compared {1 28} In the \iPC with the decrypted Directory Module 
hash value that was appended to the Directory Module. (In the preferred embodiment an ASCII version of some pre- 
determined text which is associated with the system controller/provider e.g., •'OpenTv(TM)", will be attached to precede 
respective modules before hashing so that respective hash values will equal, for example, H(OpenTv(TM))+Module). 

^5 This is indicated in FIGURE 9 by the box OTV attached to the memory 88, and is meant to imply that a digital version 
of the text ''OpenTv(TM))' , for example, may be stored in memory 88. and multiplexed with the Directory Module when 
It is read from the memory.) If the hash values are not identical, the Directory Module is presumed to include errors 
and is discarded from memory, and the fact that the module was previously loaded is erased {134} from the listing 
{114}, and the system returns to the step {108} to wait for the next packet. 

20 [0074] If the hash value of the Directory Module agrees with the appended hash value, the hash values for respective 
program modules are retrieved {129} from the directory for use in checking the integrity of received program modules. 
The system jumps to step {118} which tests whether all program modules have been loaded in memory. If they have 
not, memory addressing for the next module is arranged {1 20} and the system returns {108} to await the next appropriate 
packet. 

25 [0075] If the test at {118} indicates that the application program is completely stored in memory, the respective pro- 
gram modules are checked for transmission integrity. Respective modules are accessed {136} from memory, applied 
to the hash function element 96, and hashed {1 38}. The respective hash values are compared {1 40} in the [xPC with 
the corresponding hash values transmitted in the Directory Module, or appended to the particular module under test. 
If the hash values do not agree, the module is presumed to contain errors and is discarded {150, 152}, else a test is 

30 made {142} to determine if all modules have been checked. If they have all been tested, a check is made {146} to 
determine if a complete security checked application is resident in memory. If not, the system is returned to step {120} 
to start loading a new module. If the application is complete, It is executed {148}. In this example the program will 
instruct the C to access particular data in a program Data Module and reprogram the EPROM with the transmitted 
data. 

35 [0076] Once execution has begun, the system is programmed to continue to extract program packets from the trans- 
mitted signal. On reception, respective headers are examined for version number. If the version number for a particular 
module changes, this module will be hash processed, and If the hash value checks, the module with the new version 
number will be substituted for the prior corresponding module. 

[0077] As indicated, different apparatus in the receiving apparatus may utilize a particular transmitted application, 
40 and may be programmed to perform the requisite security processing prior to execution of the application. In the pre- 
ferred embodiment, to avoid duplication of programming or hardware, the security processing is performed by the IRD 
controller. The IRD controller will be alerted when security processing need be performed by information contained In 
the program guide. 

45 

Claims 

1 . Apparatus for receiving an executable application transmitted in modules including a Directory Module containing 
information about further modules, said Directory Module having at least an encrypted hash value over the Directory 
so Module and an encrypted certificate appended, which certificate includes an identity of the application provider, 

said apparatus characterized by: 

a memory (88) 

a detector (84) for detecting transmitted said modules and storing detected modules in said memory; 
55 means (89, fiPC) for separating said certificate from a detected Directory Module; 

a decryptor (97) for decrypting said certificate and said encrypted hash value; 

a hash function element (96) for hashing detected said Directory Module to produce a further hash value; 
a processor (^iPC) programmed for authenticating decrypted said certificate, and comparing decrypted said 
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hash value with said further hash value, and if decrypted said hash value and said further hash value are equal 
and said certificate is authentic, permitting execution of said application. 

2. The apparatus set forth in claim 1 wherein said Directory Module further includes hash values of further program 
5 modules, and said apparatus further characterized by: 

means for accessing said hash values of further program modules from detected said Directory Module; 
means for applying respective said further program modules to said hash function element for generating hash 
values over said further program modules; and wherein 
10 said processor is conditioned to compare said hash values of further program modules accessed from said 

Directory Module with corresponding hash values produced by said hash function element, and permitting 
execution of said program if at least predetermined ones of corresponding hash values are equal. 

3. The apparatus set forth in claim 1 characterized in that transmitted said Directory Module is encrypted, and said 
IS decryptor is conditioned to decrypt said Directory Module with said application provider's public key 

4. The apparatus set forth in claim 2 characterized in that said processor includes means to delete from said memory 
modules for which corresponding hash values are not identical. 

20 5. The apparatus set forth in claim 1 characterized in that said decryptor and said hash function element are subsumed 
in said processor. 

6. The apparatus set forth in claim 1 characterized in that said detector includes forward error correcting circuitry. 

25 7. The apparatus set forth in claim 1 characterized in that transmitted said executable application is transmitted in 
transport packets, each of which includes a service channel identifier, SCI D, and scrambling flags, and said detector 
includes: 

a programmable SCID detector for selecting transport packets having predetermined SCID's from a muiti- 
30 plexed stream of transport packets; and said apparatus further includes 

a descrambler responsive to said scrambling flags, for descrambling respective packets according to respec- 
tive states of said scrambling flags. 

8. The apparatus set forth in claim 1 further characterized by means for causing a display to indicate detection of 
35 signal provided by an unauthorized application provider. 

9. The apparatus set forth in claim 1 further characterized by: 

a source of a digital version of predetermined text; 
40 apparatus for preceding at least one of said modules, including the Directory Module, with said digital version 

of predetermined text, and wherein 

said hash function element is conditioned to hash said at least one module preceded with said digital version 
of predetermined text. 

45 10. The apparatus set forth in claim 9 characterized in that said predetermined text is OPENTV(TM). 

11. The apparatus set forth In claim 1 characterized in that said Directory Module includes a signature S calculated 
using a RSA algorithm with modulus N and exponent e, and includes quotients Q1 , Q2 derived from the signature 
S by division by the modulus N, and said processor is conditioned to verify said signature S using the quotients 

50 Qi and Q2 without performing arithmetic division. 

12. A method of processing executable applications which are transmitted as modules, in multiplexed packet format, 
said modules including a Directory Module containing information linking respective further application modules, 
said Directory Module having an encrypted certificate attached which contains information about the provider of 

55 the application, and which certificate is encrypted by a system provider's private key, said method characterized by; 

detecting and selecting packets including a desired application, and storing payloads of respective packets 
as respective modules; 
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selecting a Directory Module with encrypted certificate attached; 
decrypting the certificate with the system provider's public key; 
comparing information in decrypted said certificate with corresponding stored data; 
hashing ones of said application modules to produce module hash values; 
5 comparing said module hash values with corresponding module hash values transmitted in said Directory 

Module; and 

executing an application if corresponding produced and transmitted hash values are identical and decrypted 
information contained in said certificate is equivalent to said corresponding stored data. 

10 13. The method set forth in claim 12 wherein said certificate includes an application providers public key and said 
Directory Module has a hash value of said Directory Module attached, which hash value is encrypted with said 
application provider's private key, and said method further characterized by the steps of: 

extracting said application provider's public key from decrypted said certificate and separating encrypted said 
15 hash value from said Directory Module; 

decrypting encrypted said hash value using said application provider's public key; and 

comparing decrypted said encrypted hash value with a hash value of detected said Directory Module. 

14. The method set forth in claim 1 2 further characterized by appending a digital form of the text OpenTv(Tm) to said 
20 Directory Module prior too hashing said Directory Module, and hashing said Directory Module with said digital form 

of the text OpenTv(tm) appended. 

15. Apparatus for transmitting executable applications characterized by; 

25 a processor (10,11,12) for generating an executable application, and forming said application into modules 

containing portions of said application and a Directory Module containing information linking modules in an 
application; 

a hash function element (29,30) for performing one-way hash functions on modules of said application to 
produce corresponding hash values, and cooperating with said processor for inserting said hash values in 
30 said Directory Module; 

a source (10) of an application provider's public key and a certificate signed with a private key of a system 
controller and including an application provider's identifier, and a time stamp related to one of the time of 
generation and the time of expiration of the certificate; 

means (11 ,12) for attaching said application provider's public key and said certificate to said Directory Module; 
35 and 

a transport processor (14,16) for forming a time division multiplexed signal with said modules of said applica- 
tion. 

16. The apparatus set forth in claim 15 further characterized by: 

40 

encryption apparatus for encrypting a hash value of said Directory Module containing hash values of said 
application modules, with a private key of said application provider; and 

means for attaching encrypted said hash value of said Directory Module to said Directory Module. 

45 17. The apparatus set forth in claim 1 5 characterized in that ones of said modules are Data Modules in which data is 
expected to change during execution of said application, and said processor applies version numbers to respective 
modules, and changes the version number of a module when such module changes; 

said hash function element hashes each changed version of a module to produce a new hash value and 
cooperates with said processor to attach said new hash value to the module to which it corresponds. 

50 

18. The apparatus set forth in claim 15 further characterized by: 

a source of a digital version of predetermined text; 

a multiplexer for multiplexing said digital version of predetermined text with said Directory Module, wherein 
55 said hash function element is conditioned to hash the combination of said digital version of predetermined text 

and the Directory Module. 

19. A method of transmitting executable applications characterized by: 
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generating an executable application and segmenting it into nnodules; 
forming a Directory Module including information linking respective application modules; 
hashing respective modules with a one way hash function to generate hash values for respective modules; 
including hash values for respective modules in said Directory Module; 
5 accessing a certificate including an application provider's identity, which certificate is encrypted with a system 

controller's private key; and 

attaching the certificate to said Directory Module, and transmitting said application. 
20. The method set forth in claim 19 further characterized by: 

10 

hashing the directory Module with hash values included therein, to generate a Directory Module hash value; 
encrypting the Directory Module hash value; 

attaching encrypted said Directory Module hash value to said Directory Module; 

IS 21. The method set forth in claim 1 9 further characterized by; 

generating a further certificate including identification of a third party provider; 
encrypting the further certificate with the application provider's private key; and 
attaching encrypted said further certificate to said Directory Module. 

20 

22. The method set forth in claim 20 further characterized by: 

encrypting said Directory Module with an application provider's private key, and transmitting said encrypted 
Directory Module; and 
25 ^ transmitting remaining application modules in plain text. 

23. The method set forth in claim 1 9 characterized in that the step of including hash values in said Directory Module 
includes respective hash values of 128 bit length; and 

30 the step of attaching the certificate to said Directory Module includes attaching a Certificate including: 

a 32 bit certificate descriptor or flags, 
a 32 bit ID. 

a 32 bit lifetime expiration descriptor, 
a 32 bit file storage limit, 
35 a 128 bit name, and 

a 32 bit public key 



PatentansprQche 

40 

1. Vorrichtung zum Empfang einer ausfuhrbaren Anwendung, die in Modulen ubertragen wird, die ein Informationen 
uber weitere Module enthaltenes Verzeichnismodul beinhalten. das wenigstens einen verschlusselten Hashwert 
uber das Modul aufweist, und ein verschlusseltes Zertifikat als Anhang, das eine Identitat des Anwendungs-Pro- 
viders enthalt, gekennzeichnet durch: 

45 

einen Speicher (88) 

einen Detektor (84) fur die Detektion der ubertragenen Module und fur die Speicherung der detektierten Module 
im Speicher, 

Mittel (89,|iPC) fur die Trennung des Zerlifikats von einem detektierten Verzeichnismodul, 
50 - einen Entschlusseler (97) fur die Entschlusselung des Zertifikats und des verschlusselten Hashwertes, 

ein Hashfunktionselement (96) fur die Ausubung einer Hash-Funktion uber das detektierte Verzeichnismodul 
zur Erzeugung eines weiteren Hashwertes, 

ein fur eine Authentisierung des entschlusselten Zertifikats programmierter Prozessor (^PC), der den ent- 
schlusselten Hashwert mit dem weiteren Hashwert vergleicht und die Ausfuhrung der Anwendung eriaubt. 
55 wenn der entschlusselte Hashwert und der weitere Hashwert gleich sind und das Zertifikat authentisch ist. 

2. Vorrichtung nach Anspruch 1 , bei der das Verzeichnismodul Hashwerte weiterer Programmmodule enthalt, ge- 
kennzeichnet durch: 
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Mittel fur Zugriff auf weitere Hashwerte weiterer Programmmodule aus dem detektierten Verzeichnismodul, 
Mittel fur die Anwendung der jeweiligen weiteren Programmmodule auf das Hash-Funktions-Element zur Er- 
zeugung von Hashwerten uber die weiteren Programmmodule, 

einen Prozessor (89,|iPC). der konditioniert ist, die Hashwerte weiterer vom Verzeichnismodul erreichter Pro- 
5 grammmodule mit von entsprechenden Hash-Funktions-EIementen produzierten Hashwerten zu vergleichen, 

und die Ausfuhrung des Programmes zu eriauben, wenn wenigstens vorbestimmte einander entsprechende 
Hashwerte gleich sind. 

3. Vorrlchtung nach Anspruch 1 . dadurch gekennzeichnet, daG das ubertragene Verzeichnismodul verschlQsselt Ist 
10 und daS der EntschlOsseler konditioniert ist, das Verzeichnismodul mit dem offentlichen Schlussel des Anwen- 

dungs-Providers zu entsch I Ossein. 

4. Vorrlchtung nach Anspruch 2, dadurch gekennzeichnet, da3 der Prozessor Mittel enthalt, die Module aus dem 
Speicher zu entfemen, fur die keine entsprechenden Hashwerte identisch sind. 

15 

5. Vorrichtung nach Anspruch 1 , dadurch gekennzeichnet, da3 der EntschlOsseler und die Hash-Funktions-Elemente 
im Prozessor subsumiert sind. 

6. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, da3 der Detektor eine Vonwarts-Fehler-Korrektur-Schal- 
20 tung beinhaltet. 

7. Vorrichtung nach Anspruch 1. dadurch gekennzeichnet, daB 

- die ubertragene ausfOhrbare Anwendung in Transportpaketen Obertragen wird, von denen jedes einen Ser- 
25 vicekanal-ldentifikator, SCID, und VerschlOsselungs-Kennzeichen enthalt, 

- daO der Detektor einen programmierbaren SCID Detektor fOr die Auswahl von Transportpaketen enthalt, die 
vorbestimmte SCID's eines Multiplex-Stromes von Transportpaketen aufweist, 

- und daB ein EntschlOsseler f Or die Entschlusselung entsprechender Pakete in Abhangigkeit der EntschlOs- 
selungskennzeichen gema3 den jeweiligen Zustanden der VerschlOsselungs-Kennzeichen vorgesehen ist. 

30 

8. Vorrichtung nach Anspruch 1 , gekennzeichnet durch Mittel, die eine Anzeigeeinrichtung veranlassen, die Detektion 
eines von einem unberechtigten Anwendungs-Providerzur VerfOgung gestellten Signals anzuzeigen. 

9. Vorrichtung nach Anspruch 1 , gekennzeichnet durch eine Quelle einer digitalen Version eines vorbestlmmten Tex- 
35 tes. eine Vorrichtung, mit der wenigstens einem der Module einschlieOlich des Verzeichnismoduls die digitale 

Version des vorbestlmmten Textes vorgesetzt wird, und wobei das Hash-Funktions-Element konditioniert ist, we- 
nigstens ein Modul zu hashen, dem die digitale Version des vorbestlmmten Textes vorangeht. 

10. Vorrichtung nach Anspruch 9, dadurch gekennzeichnet, daG der vorbestimmte Text Open TV (TM) ist, 

40 

11. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, daG das Verzeichnismodul ein Kennzeichen S enthalt, 
das mittels eines RSA Algorithmus mit Modul N und Exponent e berechnet ist und die Quotienten Q1 und Q2 
enthalt, die von dem Kennzeichen S durch Division mit dem Modul N abgeleitet wurden, wobei der Prozessor so 
konditioniert ist, das Kennzeichen S durch Nutzung der Quotienten Q1 und Q2 ohne DurchfOhrung arithmetischer 

45 Division zu verifizieren. 

12. Verfahren zur Bearbeitung ausfuhrbarer Anwendungen, die als Module im Multiplex-Paket-Format Obertragen wer- 
den und ein Information Ober die Verbindung jeweiliger weiterer Anwendungsmodule beinhaltendes Verzeichnis- 
modul enthalten, dem ein verschlOsseltes Zertifikat beigefOgt ist, das Informationen Ober den Anwendungs-Pro- 

50 vider enthalt, wobei das Zertifikat durch einen privaten SchlOssel des System-Providers verschlOsselt ist, dadurch 

gekennzeichnet, daD 

Pakete mit einer erwOnschten Anwendung detektiert und selektiert werden und Nutzladungen jeweiliger Pa- 
kete als jeweilige Module gespeichert werden, 
55 - ein Verzeichnismodul mit belgefOgtem verschlOssettem Zertifikat ausgewahit wird, 

das Zertifikat mit dem offentlichen SchlOssel des System-Providers entschlOsselt wird, 

die Information des entschlOsselten Zertifikats mit entsprechenden gespeicherten Daten verglichen wird, 

Anwendungsmodule mit Hash-Funktion beaufschlagt werden, um Modul-Hashwerte zu erzeugen. 
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die Modul-Hash-Werte mit entsprechenden im Verzeichnis-Modul ubertragenen Modul-Hash-Werten vergli- 
chen werden und 

eine Anwendung ausgetuhrt wird, wenn entsprechende erzeugte und ubertragene Hash-Werte identisch sind 
und wenn entschlusselte Information des Zertitikats aquivalent den entsprechenden gespeicherlen Daten ist. 

5 

13. Verfahren nach Anspruch 12. bei dam das Zertifikat einen otfentlichen Schlussel des Anwendungs-Providers ent- 
halt und das Verzeichnis-Modul einen Hash-Wert des beigefugten Verzeichnis-Moduls aufweist, der nnit dem Pri- 
vatschlussel des Anwendungs-Providers verschlusselt Ist, 

dadurch gekennzeichnet, daB 

10 

des Anwendungs-Providers offentlicher SchlOssel vom entschlOsselten Zertifikat extrahiert wird und der ent- 
schlusselte Hash-Wert vonn Verzeichnis-Modul separiert wird, 

der verschlusselte Hash-Wert entschlOsselt wird durch Benutzung des otfentlichen Schlussels des Anwen- 
dungs-Providers und 

IS - der entschlusselte Wert des verschlusselten Hash-Wertes nnit einem Hash-Wert des detektierten Verzeichnis- 

Moduts verglichen wird. 

14. Verfahren nach Anspruch 12, dadurch gekennzeichnet, da3 dem Verzeichnis-Modul die digitale Form des Textes 
Open TV (Tm) zugesetzt wird, bevor auf das Verzeichnis-Modul die Hash-Funktion angewendet wird, wobei das 

20 Verzeichnis-Modul mit der zugesetzten digltalen Form des Textes Open TV (Tm) mit der Hash-Funktion beauf- 

schlagt wird. 

15. Vorrichtung zur Ubertragung ausfuhrbarer Anwendungen, 
gekennzeichnet durch: 

25 

einen Prozessor (10,11,12) fur die Erzeugung einer ausfuhrbaren Anwendung und die Formung dieser An- 
wendung in Module, die Telle der Anwendung enthalten und ein Verzeichnis-Modul mit einer die Module einer 
Anwendung verbindenden Information, 

ein Hash-Funktions-Element (29,30) fur die Durchfuhrung von Einweg-Hash-Funktionen auf Module der An- 
30 wendung, entsprechende Hash-Werte zu erzeugen, und fur die Kooperation mit dem Prozessor fur die Ein- 

fugung der Hash-Werte in das Verzeichnismodul, 

eine Quelle (10) des otfentlichen Schlussels des Anwendungs-Providers und ein Zertifikat, das mit dem pri- 
vaten Schlussel elnes System-Ubenwachers gekennzeichnet ist und eines Anwendungs-Providers Identifika- 
tor enthalt, sowie einen Zeitstempel, der auf eine der Zeit der Erzeugung und der Zeit des Ablauts des Zerti- 
35 fikats bezogen ist, 

Mittel (1 1 , 1 2), um den otfentlichen Schlussel des Anwendungs-Providers und das Zertifikat dem Verzeichnis- 
Modul belzufugen sowie 

einen Transport-Prozessor (14,16) fur die Bildung eines Zeit-Multiplex -Signals mit den Modulen der Anwen- 
dung. 

40 

16. Vorrichtung nach Anspruch 15, gekennzeichnet durch 

eine Verschlusselungsvorrichtung fur die Verschlusselung eines Hash-Wertes des Hash-Werte der Anwen- 
dungs-Module enthaltenden Verzeichnis-Moduls mit einem privaten Schlussel des Anwendungs-Providers 
45 und 

Mittel fur die Beifugung verschlusselter Hash-Werte des Verzeichnis-Moduls zum Verzeichnis-Modul. 

17. Vorrichtung nach Anspruch 15, dadurch gekennzeichnet, daf) einige der Module Datenmodule sind, in denen 
von Daten erwartel wird, daB sie sich wahrend der Ausfuhrung der Anwendung andern, und daB der Prozessor 

so Versionen-Nummern zu jeweiligen Modulen anwendet und die Versionen-Nummer eines Moduls wechselt, wenn 

sich ein solches Modul andert, wobei das Hash-Funktions-Element jede geanderte Version eines Moduls einer 
Hash-Funktion unterwirft, um einen neuen Hash-Wert zu erzeugen, und mit dem Prozessor kooperiert, um den 
neuen Hash-Wert dem Modul beizufugen, dem es entspricht. 

55 18. Vorrichtung nach Anspruch 1 5, gekennzeichnet durch eine Quelle digitaler Versionen vorbestimmten Textes, einen 
Multiplexer fur das Multiplexen der digitalen Version vorbestimmter Texte mit dem Verzeichnis-Modul, wobei das 
Hash-Funktions-Element konditioniert ist, um die Kombination der digitalen Version des vorbestimmten Textes 
und das Verzeichnis-Modul einer Hash-Funktion zu unterwerfen. 
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19. Verfahren zur Ubertragung ausfuhrbarer Anwendungen gekennzeichnet durch 

- die Erzeugung einer ausfuhrbaren Anwendung und ihre Aufteilung in Module, 

Bildung eines Verzeichnis-Moduls einschiieBlich der Information, die jeweilige Anwendungs-Module verbindet, 
5 - beaufschlagen jeweiliger Module mit einer Etnweg-Hash-Funktion zur Erzeugung von Hash-Werten fur jewei- 

lige Module, 

Einfugen von Hash-Werten fOr jeweilige Module in das Verzeichnis-Modul, 

Zugreifen auf ein Zertifikat einschljeBllch der Identitat des Anwendungs-Providers, welches Zertifikat mit dem 
Privatschlussel des System-Ubenwachers verschlOsselt ist, und 
10 - Beifugung des Zertrfikats zum Verzeichnismodul und Ubertragen der Anwendung. 

20. Verfahren nach Anspruch 19, gekennzeichnet durch 

Anwenden einer Hash-Funktion auf das Verzeichnis-Modul mit darin enthaltenen Hash-Werten, um einen 
IS Verzeichnis-Modul-Hash-Wert zu erzeugen, 

Verschlussein des Verzeichnis-Modul Hash-Wertes, 

Beifugen des verschlusselten Verzeichnis-Modul-Hash-Wertes zum Verzeichnis-Modul. 

21. Verfahren nach Anspruch 19. gekennzeichnet durch 

20 

die Erzeugung eines weiteren Zertifikats mit der Identitlkation eines dritten Providers, 
Verschlussein des weiteren Zertifikats mit dem Privatschlussel des Anwendungs-Providers und 
Beifugung des verschlusselten weiteren Zertifikats zum Verzeichnis-Modul. 

25 22. Verfahren nach Anspruch 20, gekennzeichnet durch 

die Verschlusselung des Verzeichnis-Modu Is mit dem Privatschlussel eines Anmeldungs-Providers und Uber- 
tragen des verschlusselten Verzeichnis-Moduls und 
Ubertragen verbleibender Anwendungs-Module im Klartext. 

30 

23. Verfahren nach Anspruch 19, dadurch gekennzeichnet, daf3 der Schritt der Einfugung von Hash-Werten in das 
Verzeichnis-Modul entsprechende Hash-Werte von 128 Bit Lange beinhaltet, und da3 der Schritt der Beifugung 
des Zertifikats zum Verzeichnis-Modul die Beifugung eines Zertifikats beinhaltet, das einschlieBt: 

35 - ein 32 Bit Zertifikat-Kennzeichen Oder Beschreiber, 

- ein 32 Bit ID, 

einen 32 Bit Kennzeichner des Ablauts der Lebensdauer, 
eine 32 Bit Datei-Speichergrenze, 
einen 128 Bit Namen, 
40 - einen 32 Bit offentlichen SchlDssel. 



Revendicatlons 

45 1, Appareil destin6 ^ recevoir une application executable transmise par modules comprenant un Module de Reper- 
toire contenant des informations concernant d'autres modules, ledit Module de Repertoire ayant au moins une 
valeur de hachage chiffree sur le Module de Repertoire et un certificat chiffre joint, lequel certificat comprend 
I'identite d'un fournisseur d'application, ledit appareil etant caract6ris6 par : 

so une memoire (88) ; 

un detecteur (84) pour detecter lesdits modules transmis et pour memoriser tes modules detectes dans ladite 
memoire ; 

des moyens (89, uPC) pour separer ledit certificat d'un Module de Repertoire detects ; 
un dispositif de dechiffrage (97) pour d6chiffrer ledit certificat et ladite valeur de hachage chiffree ; 
55 un element de fonction de hachage (96) pour hacher ledit Module de Repertoire detecte pour produire une 

autre valeur de hachage ; 

un processeur (m-PC) programme pour authentifier ledit certificat dechiffre, et pour comparer ladite valeur de 
hachage dechiffree avec ladite autre valeur de hachage et, si ladite valeur de hachage dechiffree et ladite 
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autre valeur de hachage sont identiques et si ledit certificat est authentique, pour permettre I'ex^cution de 
ladite application. 

2. Appareil selon la revendication 1, dans lequel ledit Module de Repertoire connprend, de plus, tes valeurs de ha- 
5 chage d'autres modules de programnne, et ledit appareil 6tant, de plus, caracterisS par : 

des moyens pour acc6der auxdites valeurs de hachage d'autres modules de programme k partir dudit Module 
de Repertoire d6tect6 ; 

des moyens pour appliquer lesdits autres modules de programme respectifs audit 6l6ment de fonction de 
10 hachage pour g6n6rer des valeurs de hachage sur lesdits autres modules de programme ; et dans lequel : 

ledit processeur est conditionn6 pour comparer lesdites valeurs de hachage des autres modules de program- 
me qui font I'objet d*un accds k partir dudit Module de Repertoire avec les valeurs de hachage correspondantes 
produites par ledit element de fonction de hachage, et permettre ['execution dudit programme si au moins des 
valeurs predeterminees parmi les valeurs de hachage correspondantes sont identiques. 

75 

3. Appareil selon la revendication 1 . caracterisd en ce que ledit Module de Repertoire transmts est chiff re, et ledit 
dispositif de dechiffrage est conditionn6 pour dechiffrer ledit Module de Repertoire avec ladite cie publique du 
fournisseur de I'applicatlon. 

20 4. Appareil selon la revendication 2, caracterise en ce que ledit processeur comprend des moyens pour effacer de 
ladrte memoire les modules pour lesquels les valeurs de hachage correspondantes ne sont pas identiques. 

5. Appareil selon la revendication 1 , caract6rise en ce que ledit dispositif de dechiffrage et ledit element de fonction 
de hachage sont sous-additlonnes dans ledit processeur. 

25 

6. Appareil selon la revendication 1, caracterise en ce que ledit detecteur comprend des elements de circuit de 
correction d'erreurs en avant. 

7. Appareil selon la revendication 1 , caracterise en ce que ladite application executable transmise est transmise dans 
30 des paquets de transport, chacun d'eux comprenant un identificateur de canal de service, SCID, et des indicateurs 

de brouillage, et ledit detecteur comprend : 

un detecteur d'identificateur de canal de service programmable pour seiectionner les paquets de transport 
comportant des identificateurs de canal de service predetermines k partir d'un flot multiplexe de paquets de 
35 transport ; et ledit appareil comprend, de plus : 

un dispositif de desembrouillage sensible auxdits indicateurs de brouillage, pour desembrouiller les paquets 
respectifs selon les etats respectifs desdits indicateurs de brouillage. 

8. Appareil selon la revendication 1 , caracterise, de plus, par des moyens pour provoquer un affichage pour Indiquer 
40 la detection d'un signal fourni par un fournisseur d'application non autorise. 

9. Appareil selon la revendication 1 , caracterise, de plus, par : 

une source d'une version numerique du texte predetermine ; 
^ un appareil pour faire prec6der au moins Tun desdits modules, comprenant le Module de Repertoire, de ladite 

version numerique du texte predetermine, et dans lequel : 

ledit element de fonction de hachage est conditionne pour hacher ledit au moins un module precede de ladite 
version numerique du texte predetermine, 

so 10. Appareil selon la revendication 9, caracterise en ce que ledit texte predetermine est OPENTV(TM). 

11. Appareil selon la revendication 1, caracterise en ce que ledit Module de Repertoire comprend une signature S 
calcuiee en utilisant un algorithme RSA avec un module N et un exposant e, et comprend des quotients Q1, Q2 
deduits de la signature S par la division par le module N, et ledit processeur est conditionne pour verifier ladite 

55 signature S en utilisant les quotients Q1 et Q2 sans effectuer de division arithmetique. 

12. Procede de traitement d'applications executables qui sont transmises en tant que modules, dans un format de 
paquets multiplexes, lesdits modules comprenant un Module de Repertoire contenant des informations liant les 
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autres modules d'application respectifs, ledit Module de Repertoire ayant un certificat chiffr6 joint qui contient des 
informations concemant le fournisseur de rapplication, et lequel certificat est chiffr6 par la cl6 privee d'un fournis- 
seur de syst6me, ledit precede etant caracterise par : 

s la detection et la selection de paquets comprenant une application souhait6e, et la memorisation des charges 

utiles des paquets respectifs en tant que modules respectifs ; 
la selection d'un Module de Repertoire avec un certificat chrffr^ joint ; 
le dechiffrage du certificat avec la c\6 publique du fournisseur de systems ; 

la comparaison des informations dans ledit certificat d6chiffr6 avec des donn6es m6moris6es 
10 correspondantes ; 

le hachage de certains desdits modules d'application pour produire des valeurs de hachage de module ; 
la comparaison desdites valeurs de hachage de module avec les valeurs de hachage de module correspon- 
dantes transmises dans ledit Module de Repertoire ; et 

rex6cution d'une application si les valeurs de hachage produites et transmises correspondantes sont identi- 
fy ques et si les informations ddchiffrdes contenues dans ledit certificat sont dquivalentes auxdites donn^es 
m6moris6es correspondantes. 

1 3. Proc6de selon la revendication 1 2, dans lequel ledit certificat comprend la cl6 publique du fournisseur d'application 
et ledit Module de Repertoire a une valeur de hachage dudit Module de Repertoire joint, laquelle valeur de hachage 

20 est chiffrde avec ladite c\6 privee du fournisseur d'application, et ledit proc^de est, de plus, caracterise par les 

etapes consistant ^ : 

extraire ladite cie publique du fournisseur d'application dudit certificat dSchiffre et s^parer ladite valeur de 
hachage chiffree dudit Module de Rdpertoire ; 
25 dechiffrer ladite valeur de hachage chiffree en utiHsant ladite cie publique du fournisseur d'application ; et 

comparer ladite valeur de hachage chiffree dechiffr^e avec une valeur de hachage dudit Module de Repertoire 
detecte. 

14. Proc6d6 selon la revendication 12, caract6ris6, en outre, par I'addition d'une forme num6rique du texte OPENTV 
30 (TM) audit Module de Repertoire avant le hachage dudit Module de Repertoire, et de hacher ledit Module de 

Repertoire avec ladite forme numerique du texte OPENTVfTM) joint. 

15. Appareil destine ^ transmettre des applications executables, caracterise par : 

35 un processeur (10, 11 , 12) pour generer une application executable, et pour former ladite application en des 

modules contenant des parties de ladite application et un Module de Repertoire contenant des informations 
liant les modules dans une application ; 

un element de fonction de hachage (29, 30) pour execute r des fonctions de hachage untdirectionnel sur les 
modules de ladite application pour produire des valeurs de hachage correspondantes, et pour cooperer avec 
40 ledit processeur pour inserer lesdites valeurs de hachage dans ledit Module de Repertoire ; 

une source (10) de cie publique d'un fournisseur d'application et un certificat signe avec une cie privee d'un 
contrdleur de systeme et comprenant I'identificateur d'un fournisseur d'application. et un horodatage concer- 
nant i'une de I'heure de generation et de I'heure d'expiration du certificat ; 

des moyens (11,12) pour attacher ladite cie publique du fournisseur d'application et ledit certificat audit Module 
45 de Repertoire ; et 

un processeur de transport (14, 16) pour former un signal multiplexe par repartition dans le temps avec lesdits 
modules de ladite application. 

16. Appareil selon la revendication 15, caracterise. de plus, par: 

50 

un appareil de chitf rage pour chiff rer une valeur de hachage dudit Module de Repertoire contenant les valeurs 

de hachage desdits modules d'application, avec la cie privee dudit fournisseur d'application ; et 

des moyens pour attacher ladite valeur de hachage chiffree dudit Module de Repertoire audit Module de 

Repertoire. 

55 

17. Appareil selon la revendication 15, caracterise en ce que certains desdits modules sont des Modules de Donn6es 
dans lesquels les donnees sont susceptibles de changer pendant I'execution de ladite application, et ledit proces- 
seur applique des numeros de version aux modules respectifs, et change le numero de version d'un module lorsque 
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ce module change ; 

ledit element de fonction de hachage hache chaque version modif iee d'un nnodule pour produire une nouvelle 
valeur de hachage et coopere avec ledit processeur pour attacher ladite nouvelle valeur de hachage au module 
auquel elle correspond. 

18. Appareil selon la revendicatlon 15, caract6ris6. de plus, par: 

une source d'une version numerique d'un texte predetermine ; 

un multiplexeur pour multiplexer ladite version numdrique du texte pr6d6termin6 avec ledit Module de Reper- 
toire, dans lequel ledit element de fonction de hachage est conditionn6 pour hacher la combinaison de ladite 
version num6rique du texte pr6d6termin6 et du Module de Repertoire. 

19. Proced6 de transmission d'applications executables, caracterise par: 

la generation d'une application executable et la segmentation de celle-ci en modules ; 
la formation d'un Module de Repertoire comprenantdes informations liant les modules d'application respectifs ; 
le hachage des modules respectifs avec une fonction de hachage unidirectionnel pour generer des valeurs 
de hachage pour les modules respectifs ; 

I'introduction des valeurs de hachage pour les modules respectifs dans ledit Module de Repertoire ; 
I'acces a un certificat comprenant i'identite d'un foumisseur d'application, lequel certificat est chiffre avec la 
cie privee d'un contrCIeur de systeme ; et 

I'attachement du certificat audit Module de Repertoire, et la transmission de ladite application. 

20. Procede selon la revendtcation 1 9, caracterise, de plus, par : 

le hachage du Module de Repertoire avec les valeurs de hachage incluses dans celui-ci, pour generer une 

valeur de hachage de Module de Repertoire ; 

le chlffrage de la valeur de hachage du Module de Repertoire ; 

I'attachement de ladite valeur de hachage du Module de Repertoire chiffree audit Module de Repertoire. 

21. Procede selon la revendicatlon 19, caracterise, de plus, par : 

la generation d'un autre certificat comprenant {'identification du foumisseur d'une troisieme partie ; 
le chiffrage de I'autre certificat avec la cl6 privee du foumisseur d'application ; et 
I'attachement dudit autre certificat chiffre audit Module de Repertoire. 

22. Procede selon la revendicatlon 20, caracterise, de plus, par : 

le chiffrage dudit Module de Repertoire avec la cte privee d'un foumisseur d'application, et la transmission 

dudit Module de Repertoire chiffre ; et 

la transmission des modules d'application restants en clair. 

23. Precede selon la revendicatlon 1 9, caracterise en ce que I'etape consistant k inclure des valeurs de hachage dans 
ledit Module de Repertoire inclut des valeurs de hachage respectives d'une longueur de 128 bits; et 

I'etape consistant k attacher le certificat audit Module de Repertoire comprend I'attachement d'un Certificat 
comprenant : 

un descripteur de certificat de 32 bits ou des indicateurs. 
une identification de 32 bits, 

un descripteur d' expiration de duree de validite de 32 bits, 
une limite de memorisation de fichier de 32 bits, 
un nom de 128 bits, et 
une cie publique de 32 bits. 
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STAFTT: APPLICATION DESCRIPTOR (FIXED LENGTH PART): 



- PRODUCER CERTIFICATE OFFSET (CERTIFICATE ADDRESS = START + OFFSET) 
-APPUCATION NAME OFFSET (APPLICATION NAME ADDRESS = START + OFFSET) 
APPLICATION ID (32 BITS) 

APPLICATION UFE EXPIRATION (32 BITS) 

APPLICATION AUTHORIZATION MASK (32 BITS) 

APPLICATION FILE STORAGE LIMIT (32 HITS) 

APPLICATION MINI REQUIREMENTS (32 BITS) 

APPLICATION MODULE NUMBER (32 BITS) 

FOR EACH MODULE. MODULE DESCRIPTOR (FIXED LENGTH PART): 
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MODULE REQUIREMENT 
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